home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000109_icon-group-sender _Thu May 20 01:22:30 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  3KB
  1. Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 20 May 1993 15:41:54 MST
  2. Received: by owl.cs.arizona.edu; Thu, 20 May 1993 15:41:52 MST
  3. Date: 20 May 93 01:22:30 GMT
  4. From: world!ksr!tim@uunet.uu.net  (Tim Peters)
  5. Organization: Kendall Square Research Corp.
  6. Subject: Re: A bug? Or a feature?
  7. Message-Id: <26810@ksr.com>
  8. References: <12743@sun13.scri.fsu.edu>
  9. Sender: icon-group-request@cs.arizona.edu
  10. To: icon-group@cs.arizona.edu
  11. Status: R
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13.  
  14. In article <12743@sun13.scri.fsu.edu> nall@ibm12.scri.fsu.edu (John Nall) writes:
  15. > ...
  16. > The Icon reference manual says (and I quote):
  17. >
  18. >     X1 op:= X2
  19. >
  20. >     "performs the operation X1 op X2 and assigns the result to X1
  21. >
  22. > All well and good, and by and large it does exactly that.  With a
  23. > slight variation, however.  To wit: it actually:
  24. >
  25. >     "performs the operation X1 op (X2) and assigns the result to X1"
  26. >                                   ^  ^
  27. > ...
  28. > A bug?  Or a feature?
  29.  
  30. A harmless ambiguity <grin>.  I'm sure Icon's working as intended here,
  31. but there are many places in the language where a precise description of
  32. the semantics might scare off the manual's primary audience <wink>.
  33.  
  34. There's another (well, at least one more) ambiguity in the text you
  35. quote, to wit how many times X1 is evaluated.  An example to show the
  36. difference:
  37.  
  38. global i1, i2
  39.  
  40. procedure main(switch)
  41.    i1 := 1
  42.    i2 := 2
  43.    if *switch > 0 then {
  44.       write( "pick() +:= 10" )
  45.       pick() +:= 10
  46.    } else {
  47.       write( "pick() := pick() + 10" )
  48.       pick() := pick() + 10
  49.    }
  50.    write( i1, " ", i2 )
  51. end  # procedure main
  52.  
  53. procedure pick()
  54.    static i
  55.    initial i := 0
  56.    case i +:= 1 of {
  57.       1 : return i1
  58.       2 : return i2
  59.    }
  60. end  # procedure pick
  61.  
  62. If run without arguments, it prints
  63.  
  64. pick() := pick() + 10
  65. 12 2
  66.  
  67. If run with an argument,
  68.  
  69. pick() +:= 10
  70. 11 2
  71.  
  72. The point is that the left-hand side is evaluated exactly once in an
  73. augmented assignment, & I'm not sure The Bible ever says that except for
  74. an implication on pg 74 (where it notes that augmented assignment "is
  75. particularly useful for tables [because the table lookup is done only
  76. once]").
  77.  
  78. Both behaviors (evaluating the LHS once, & evaluating the RHS without
  79. regard to the LHS) are the norm for languages with augmented assignment,
  80. but I think it's been historically rare for language manuals to say so
  81. clearly.  For a recent example of one that does, check out the
  82. explanations of augmented assignment in the ISO C standard.  It will make
  83. you appreciate the friendly-though-incomplete explanation in the Icon
  84. manual <smile>.
  85.  
  86. but-agreeing-that-a-pair-of-parens-in-the-text-would-help-clarify-one-
  87.    of-the-potential-confusions-ly y'rs  - tim
  88.  
  89. Tim Peters   tim@ksr.com
  90. not speaking for Kendall Square Research Corp
  91.